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(57) Abstract 

A system for the open distribution of electronic money is provided having a customer tnisted agent assodated witli a fiist money 
module, a mcicbant trusted agent dial established a first cryptographically secure session with die customer trusted agent and associated 
with a second money module. Where the money modules establish a second ciyptographicalfy secure session. Tbc customer trusted agent 
;]»Ovidcs electronic money purchase or sale infonnation and an acmunt credp-^'al to die meidiant trusted agent, and fte merchant tnisted 
a^t provides a receipt ticket to the customer tmsted agent The merchant tnisted agent accesses an aufliorizati<m netwoik and initiates an 
" ion process ming infbrination from die electronic money purdi^ 

on, die merchant trusted ageitt irutiates a transfer of electronic money frwn the second money roodute to die first mon^ inc 
'Of a purchase, or initiates a transfer of dectrcmic money fran the first money module to die second money module n\ tfie 
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TjliaSTED AGENTS FOR OPEN DISTRIBUTION OF ELECTRONIC MONEY 

FIELD OF THE INVENTTO^ 
The present invention relates to a system for 
facilitating the distribution of electronic money. In 
particular, the system utilizes tamper-proof electronic 
5 units, referred to as "trusted agents", in combination with 
money modules to create a secure transaction environment in 
which customers may purchase or sell electronic money from 
merchants using credit or debit card credentials, 

^0 Background of the Invention 

Numerous electronic payment systems are currently 
being developed to accommodate the growth in electronic 
commerce. One method of electronic payment is described in 
my co-pending U.S. patent applications 07/794,112 filed 

15 November 15, 1991, 08/234,461 filed April 28, 1994, and 
08/427,287 filed i^ril 21, 1995, the disclosures of which 
are incorporated herein by reference. These applications 
disclose an electronic monetary system for implementing 
electronic money payments as an alternative medium of 

20 exchange to cash, checks, credit cards, debit cards, and 
electronic funds transfers. In particular, the described 
system uses money modules packaged in tamper-proof housings 
to store and transfer electronic notes. Money module 
payments may be either real-time, off-line payments between 

25 money modules (e.g. , between a money module contained within 
a customer's "electronic wallet" and a money module 
contained within a merchant's point-of-sale terminal), or 
on-line payments for network . ee^cyices such as information 
retrieval and telephone calls, or for purchasing airline 

30 tickets, theater tickets, etc. 

The trusted agents discussed herein are fully 
described in my co-pending U.S. Patent application 
08/234,461, filed i^ril 28, 1994, the disclosure of which is 
incorporated herein by reference. That application 

35 describes a system for enafellf^^'^felS^ aecure delivery of 
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electronic merchandise with real-time anonymous payment or 
authorization-based payment. The system allows both the 
customer and merchant to feel secure that their interests 
are being served. 

cash is widely available from banks and merchants 
Electronic money, just like cash, needs to be widely 
available in order to gain general acceptance. The present 
invention describes how trusted agents can facilitate the 
distribution of electronic money through merchants which are 
connected to a payment authorization network. T^i^ 
distribution transaction can be accomplished locally or 
remotely from the merchant. greatly increasing the 
distribution points beyond the banking network. Also, the 
disclosed distribution system can exchange one monetary unit 
for another. For example, one could obtain U.S. dollars 
from a British pound account, 

07/794 ™°««tary system application 

07/794.112 disclosed how cash can be exchanged for 
electronic money and vice-versa. such a transaction was 
accomplished locally at a bank teller or ATM machine since 
cash was dispensed. Electronic money could also be 
dispensed locally if an ATM or point of sale terminal is 
modified to dispense the electronic money and the terminal 
could guarantee the security of the transaction. The 
present invention describes how electronic money can be 
processed remotely and securely from a merchant without a 
special terminal such as an AIM or POS terminal. For the 
customer, the security of the transaction is assured by the 
use of a trusted agent. There is no need for special 
terminals, which unbeknown to the customer, could have 
Trojan horse processes which take the customer's electronic 
money or capture his secret bank access information. 

nmvi^. °^ P^^^^'^t invention to 

S^S^.^°tem using trusted agents for the 




distribution of electronic money through merchants or bsoiks 
connected to a payment authorization network. 

It is a further object of the present invention 
to provide a system for buying or selling electronic money 
remotely and securely from a merchant without a special 
terminal . 

It is yet a further object of the present 
invention to provide a system that allows a merchant to 
satisfy a customer's need for electronic money even if the 
merchant does not have electronic money initially in his 
possession. 

It is yet a further object of the invention to 
increase the distribution of electronic money without the 
need to sign-up numerous banks to participate in the 
electronic monetary system. 

In the present invention, a system for the open 
distribution of electronic money is provided having a 
customer trusted agent, a first money module associated with 
the customer trusted agent and with which it securely 
communicates, a merchant trusted agent that establishes a 
first cryptographically secure session with the customer 
trusted agent, and a second money module associated with the 
merchant trusted agent with which it securely commxinicates . 
The first and second money modules establish a second 
cryptographically secure session. The customer trusted 
agent provides electronic money purchase information and an 
account credential to the merchant trusted agent, and the 
merchant trusted agent provides a receipt ticket to said 
customer trusted agent • The merchant trusted agent accesses 
an authorization network and initiates an authorization 
process using information from the electronic money purchase 
information and the account credential. Vpon receiving 
authorization, the merchant trusted agent initiates a 
transfer of electronic money from the second money module to 
the first money module. 

In the event the merchant trusted agent does not 
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have Buffxcient funds in its associated .oney module, it 
attempts to acquire electronic money from affiliated 
transaction devices or by withdrawing electronic money from 
a^bank at which the merchant has an account and which is an 
electronic money provider. The described system 

architecture and protocols also support the sale of 
electronic money by the customer to the merchant, which is 
analogous to a deposit transaction. 

Pe^criptinn of i->.^ ^^^^...cy^^^ 

The invention will be described in greater detail 
below wxth reference to the attached drawings, of which: 

Figure i is a diagram showing the trusted 
agent /money module interaction. 

Figure 2 illustrates the sections and fields of 
various tickets. 

Figure 3 illustrates the components of a 

transaction device. 

Figures 4A-4D illustrate the functional components 
Of trusted agents. 

Figure 5 is a diagram showing the network 
structure for open distribution of electronic money. 

Figure 6A illustrates a Commit protocol. 

Figure 6B illustrates an Abort protocol. 
. Figures 7A-7G illustrate an Authorization-Based 
Purchase/Sale of Electronic Money protocol. 

Figures 8A-8E illustrate an Establish Session 

protocol . 

Figure 9 illustrates a Send Message protocol. 
Figure 10 illustrates a Check Credential protocol 
Figure ll illustrates an Abort Transaction 

protocol . 

Figures 12A-12E illustrate a Money Module Payment 

protocol . 

Figure 13 shows the various jmS^&asmSmtion 
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layers established among trusted agents and money modules. 

Figures 14A-14E illustrate an Establish Session 
protocol for money modules. 

Figure 15 illustrates a Send Routed Message 

protocol . 

Figure 16 illustrates a Send MM/TA Message 

protocol . 

Figure 17 illustrates a Send TA/MM Message 

protocol . 

Figures 18A-18B illustrate an Abort Transaction 
protocol for money modules. 

Figure 19 illustrates a Send E- Routed Message 

protocol . 

Figures 20A-20B illustrate a Trcuasfer Notes 

protocol . 

Figure 21 illustrates a Commit protocol for money 

modules • 

Description of the Preferred E mbodiment 
As described in my co-pending U.S. application 
08/234,461, a trusted agent is a combination of hardware and 
software components. It is tait5)er- proof cind contains secure 
protocols which cooperate with a money module to synchronize 
secure payment to delivery. Money modules are tanqper- proof 
devices capable of storing and transferring electronic 
money. The electronic money is preferably in the form of 
electronic notes that are representations of currency or 
credit. Money modules are also capable of establishing 
cryptographically secure comir(\micat ion sessions with other 
devices . The preferred embodiment of the present invention 
Utilizes the transaction money modules described in my co- 
pending U.S. patent applicatiQjis 07/794,112 and 08/427,287. 

The trusted agents when making purchases over a 
network, exchange electronic merchandise and payment. In 
the present invention, as showi in Figure 1, the merchant's 
35 trusted agent 4 (MTA); sendfi a receipt ticket to the 
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customer' B trusted agent 2 ,CTA) . In return, the customer- s 
n»ney module 6 sends electronic ™oney to the merchant's 
money module e via CTA 2 and »rrA 4 when the customer is 
selling electronic money. „ the customer is purchasing 
electronic money, then the electronic money flows fro. the 
merchant to the customer. 

Ticket^ 

Referring to Figures 1 and 2, a ticket 8 is an 
electronic item created by a MTA 4 and transferred to a CTA 
2 during a transaction. Tickets may be thought of as the 
property of the trusted agents. A customer whose CTA 2 has 
Dust received a ticket 8 may only use that ticket upon 
successful completion of the transaction. 

trusts. ^-^---^^ in the 08/234,461 application, 

trusted agents support a variety of ticket types used for 
various purposes. However, of primary importance for the 
present invention are credential tickets and electronic 

IZLr'^rr ^ credential ticket 

Identifies the "owner., and permits specific privileges. 
Exatnples of credentials include credit and debit cards A 
credit or debit card ticket can be presented 'for 
authorization-based payment, a customer's receipt ticket 
identifies the particulars of a distribution transaction 
(buying or selling of electronic^ money) , and may be used by 
the customer in a dispute scenario. 

Figure 2 shows a preferred embodiment of a ticket 

Identi^ie^ ^, Components 12, issuer Signature 14, issuer 
certificate. 16 Transfer History 18 and Sender Signatures 
20 The auctions, in turn, are comprised of various 
in£ormatic>n|containing fields, 

h ' ."^^ Identifier section 10 has a field 22 which 
holds information that identifies the merchant or authority 
creating th^ ticket. Such information, for example the 
mithoritys name, is copied from a merohant or 
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authority credential held by the ticket issuer. The field 
22 also contains the e3q)iration date of the merchant or 
authority credential, A field 24 contains the receiving 
trusted agent's identification number. The field 24 also 
contains the expiration date of the ticket receiver's 
5 trusted agent credential. A field 26 designates the ticket 
type (e.g., credit or debit card ticket, receipt ticket, 
etc. ) . 

The Con?)onentB section 12 contains the basic 
ticket content which varies depending upon the ticket type 
10 and its specific purpose. Figure 2 shows examples of 
components found in different ticket types . 

A credential ticket such as a credit or debit card 
may have: a Bank ID field 36 specifying the credential 
owner's bank; an Accoxint Number field 38; a Valid Prom Date 
15 field 40; an Expiration Date field 42; and a Customer Name 
field 44. 

An electronic money purchase receipt ticket may 
have: a Bank ID field 46 specifying the bank identified in 
the customer's credential; an Account Number field 38 

20 specifying the account number identified in the customer's 
credential; a Type of Transaction field 50 specifying 
whether the transaction is an electronic money purchase or 
sale; an Authorization Amount field 52; an Amount Sent or 
Received field 54; a Merchant Fee field 56; and a Date of 

25 Transaction field 58. The authorization amount equals the 
amount received plus the merchant's fee for the purchase 
transaction or the amount sent minus the merchant's fee for 
a sale. 

The issuer Signature section 14 of a ticket 8 
30 holds a digital signature, formed by the ticket creator, 
over the Identifier and Components sections 10, 12. Such 
signature is made using a private key belonging to the 
issuer's trusted agent. The Issuer Certificate section 16 
contains a certification by a trusted third party 
(hereinafter referred as "Trusted Agency") used in 
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conjunction with the issuer signature to verify the 
authenticity of the issued ticket 8. Such certification is 
xn the^ form of a certificate belonging to the issuer's 
trusted agent. The general use of certificates and digital 
signatures is known and described, for example, in D W 
Dav.es and W.L. Price, Security For Computer Networks (John 
Wiley & Sons, 1984) . 

infor™..- " -stains 

information generated when tickets are transferred between 
trusted agents after the initial issuing of the ticket 8 by 
a merchant or authority, a Receiver iD's field 28 contains 
the recexvxng trusted agent's identification number. a 
sender ID'S field 30 contains the sending trusted .gent's 
xdentxf xcation number. A Sender Certs field 32 contains the 
sending trusted agent's certificate. A Date/Times field 34 
contains the date and time of transfer of the ticket 8. As 
subsequent transfers are made, additional receiver and 
sender iD's, sender certificates, and dates and times are 
appended to each field, thus creating a list of transfer 
history information. It may be noted that the trusted agent 
ID found m the Receiver field of the Identifier section, 
should be the same as the first ID in the Sender ID's field 

in addition, whenever a ticket 8 is transferred 
between trusted agents, the sender digitally signs the 
ticket over the five preceding ticket sections using a 
private key belonging to the sender's trusted agent. The 
sender Signatures section 20 is then updated by appending 
the newly created digital signature, thus forming a list of 
sender signatures. 
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Transarf lon n«»y^ooc^ 

emh.d*.. ^^'"^'^ '° •« "^--Bted agent 120 1b 

I^^L, • " O-^" The transaction 

devxoe 122 xe co»^oeed of three ™aJor components for both 
the merchant and the customer. There is a host process^ 
4, a trusted agent 120, and a money module 6 " 
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coirponents are connected, for exanple, by a bus 126. When 
trusted agent 120 is a MTA 2, the device 122 is referred to 
as a merchant trcinsaction device (MTD) . When trusted agent 
120 is a CTA 4, the device 122 is referred to as a customer 
trcLnsaction device (CTD) . 

Figure 3 shows the functional coi!5)onents of the 
host processor 124, The host processor provides the 
following functions: Communications 128, Transaction 
Applications 130, Human/Machine Interface 132, Date/Time 
136, and a Message Msmager 134. 

The Communications function 128 supports 
communications between the transaction device 122 and the 
outside world. Such comrmini cat ions may be wired or 
wireless, broad or narrow betnd, so long as communications 
are cortpatible between the devices. The Communications 
function 128 sets up the connection between two transaction 
devices 122, or connects a transaction device to a network 
for indirect connection to another trauisaction device or a 
trusted server. 

Transaction implications 130 may perform a variety 
of tasks. For exan5>le, a transaction application may shop 
the merchant networks for the lowest merchant transaction 
fee and/or the best exchange rate in an electronic money 
purchase or sale transaction. In general, a transactipn 
device 122 contains all the processes to choose, buy and 
25 possibly use electronic objects, electronic money, 
credentials, and other tickets 8, or the processes to sell 
the same. 

The Human/Machine Interface function 132 provides 
the look and feel of the trauisactlon device 122. It could 
include a keyboard, mouse, pen, voice, 1:ouch screen, icons, 
menus, etc. The Human/Machine Interface 132 communicates 
with other functions in the trusted agent 120 and the money 
module 6 through the message manager 134. in some 
applications a Human/Machine Interface 132 may not be 
35 necessary, for exair5)le, in a' 'fixily^aut^omated merchant 
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transaction device. 

""'''■'^■"^ ^-^^ionise is set by the owner of 
the traneactxon device 122 and includes date, time and ti„.e 
.one The Date/Time info^ation is fed to the .^dded 
trusted agent 120 whenever the trusted agent is opened for 

The Message Manager 134 routes inter-host messages 
I^naVrr?" '--»=tion devices, and messages 

among the host processor 124. the trusted agent 120 and the 

money module 6. uae 

Trusted »~^tf, 

t„..^ ^^^"^ '"^ functional components of a 

trusted agent X20. The conteo^lated system for open 
elect^^nic commerce uses three types of trusted agent 120 
Which differ in certain unique Transactor functions 14G that 
th^provide. Pigure 4B shows the transactor f Jt^ 
found in a era 2. Pigure 4C shows the transactor functions 
found in a KTA 4. Pigure 4D shows the transactor functio^ 
found in an Authority Trusted ^gent (ATA) which, in turn, is 
embedded ^ an Authority Transaction Device ,AT«, . at^ are 
associated with credential issuing authorities such as " 

An E:ct.mal Interface function 138 provides 
physical communication with the host processor 124 and the 
« money module s of the transaction device 122 in whict ^ 
rusted agent 120 is embedded. A Message Interface funct ^ 
140 processes and routes inter-agent and intra-agent 
«e.».g^s, # session Manager function 142 set, up and br^a"! 
down i„ter..ge„t sessions and agent to trusted sert« 
30 sessions. A security Manager function 144 maintH^ 
security ittormation (e.g., a trusted agent certif'ate 
an untrusted agent list) . . 

agent list) and establishes secure 

co^mmication with a counterparty trusted agent (via^H 
host ptDcesW 124) and with the loc»l ^ 7, 

w M.. ..i*-ifclB*- i " moaey module 6 within 

35 the safte^'eEaiBiction device 125 ti,. 

r. i n itillim tri i ^'^^oe "2. The Transactor function 



20 




146 provides the protocols to perfonn a transaction. 
Customer, merchant and authority transactors are used for 
CTAs, MTAs and ATAs, respectively* 

Figure 4B shows the customer transactor functions • 
A Purchase function 158 exchanges payment for ticlcets 8 and 
electronic objects. A To Host function 160 provides an 
interface to the transaction device's host processor 124. 
A Present Ticket function 164 presents tickets 8 to obtain 
information or services . An Acquire Credential function 166 
interacts to receive a credential ticket. A Tran Log 
function 162 maintains a log of trusted agent transactions. 
Both CTAs 2 and MTAs 4 maintain a transaction log which 
stores the following information: transaction type (e.g., 
ticket type) ; a pre -transact ion ticket image; a post- 
transaction ticket image; dispute information including the 
date of dispute (as maintained by each trusted agent in the 
dispute dialog), status, and merchant resolution (e.g., 
replace, refund, denied) ; and recertifying infonnation 
(e.g., date of recertif ication) . An Initiate Dispute 
function 168 presents electronic merchandise if a tmstomer 
is dissatisfied. 

Figure 4C shows the merchant transactor fimctions. 
A Purchase function 170 exchanges tickets 8 and electTOTiic 
objects for payment. A To Host function 172 provides an 
interface to the transaction device's host processor 124. 
A Receive Ticket function 176 processes a received ticket 8 
to provide service or infoannation. An Acquire Credential 
ftmction 177 obtains a merchant credential. A Tran Log 
fiinction 174 maintains a log of trusted agent transactions. 
A Resolve Dispute function 178 receives tickets 8 and 
electronic objects to resolve a customer complaint. 

Figure 4D shows the authority traiusactor 
functions. A Create Credential function 180 constructs and 
delivers credential tickets to a requestor. A To Host 
function 182 provides an interface to the transaction 
device's host processor 124. A Receive Ticket function 184 



proWBse, a Received ticket 8 to provide service or 
Information. A Revalidate Credential function 1S6 accepts 
a current credential and reissues the credential with a neC 
«<piration date. A Tran function U3 n»intains a log If 
traneactxone. An Acquire Credential function 185 obtains an 
authority credential. 

Referring again to Figure 4A. a To Honey Module 
function 150 ccnmiunicates with the noney n«rfule 6 i„ the 
same transaction device 122 to provide payment a 
cryptography function 152 provides public key and sy,™etric 
^cryptographic functions. Any well known pub^c an^ 
sy^etric key cryptography techniques ».y be used, for 
example, RSA ««, DES. A Ticket Holder function 148 creates 

Z T A 1 * ^ « "a 

»L™ '^""'""'^ generates 

fu^^on"^" '° "-^'^^^ »ate/Ti«e 

function 154 ™„ages the date «,d tl,« delivered from the 
host processor 124 to date tickets 8 and validate 
certificates and presented tickets. current =iock 
information is fed to the trusted agent 120 every time the 
trusted agent is opened (i.e., signed on for use, and 
naintained until the trusted agent is closed. 

The trusted agent/money module hardware may 
^nll , T ^ "icrocontroller (e.g.. ^Zl 

196 family) for executing the transaction protocols, a high- 
speed volatile memory (e.g. , SRAM) for storing the operating 
^Btem parts of the applications, cryptography, etc during 
execution, a non-volatile memory (e.g., flash memory, for 
Btoring the operating system, applications, tickete 
electronic money, logs, etc., an integrated circuit clock 
for providing a time reference, a batter, for the clock, and 

™r""^ ""-^ — ' -"-e- 



System Qvt^Tv^cfu. 
Figure 5 shows the general network archlt 
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the contemplated eystem for open distribution of electronic 
money. Customer transaction device 188 can communicate with 
a merchcuit through any gateway network 190. The customer 
can search out merchants' electronic space for the purchase 
or sale of electronic money, and select the merchant 
5 offering the lowest transaction fee and/or exchange rate. 
The system then provides for secure authorization -based 
purchase/sale of electronic money via credit or debit card. 
This is accomplished by the customer presenting credit or 
debit card information stored within the trusted agent 120 

10 as a credential. 

In the pre f erred embodiment , the gateways 190 
provide CTDs 188 with access to local merchant networks 134 
that are connected to ^f^Ds 198 . The mercheint network 134 is 
connected to the merchant's bank network 200 that, as 

15 described in my co-pending application 07/794,112, has 
access to electronic money via money generator module 202, 
teller money module 204, and banking system 206 which 
provides the bank's on-line accounting system. 

The credit or debit card credentials are processed 

20 to obtain authorizations for the crediting or debiting of 
the customer's bsmk account via authorization network 208. 
Card authorization is well known in the art and typically 
involves the card issuer or its agent authorizing a. 
particular payment when sufficient funds are present or the 

25 amount is within the card holder's credit limit. 
Authorization networks also credit a customer's account, for 
example, when making a refund. Authorization network 208 is 
connected to the customer's bank netyrorl^^ :^0D which, in turn, 
is coimected to banking system 206, .which contains the 

30 customer's bank account. 

This architecture allows subsbribers who are not 
customers of electronic monetary system member batnks to 
nevertheless gain access to electronic money via merchants 
who do have access to member banks • This system structure 

35 allows the sxibscriber to buy or sellf fel^i^&fc^riic money from 
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many distribution points, which from the subscriber's point- 

llZr " Withdrawing or depositing 

electronic n>oney from/to their bank account. 

It should also be noted that «, electronic 
^netary syste. bank could also provide the above-de.cri^: 
distribution service via an MTD 198. i„ this case, of 
~urse there would be no need for a merchant network 13! 
The bank network 200 would singly connect to a ,«>ney 
generator ,„dule «2, teller ^ney „»dule 204, banking 
system 20.. ^ x„. authorization network 208. and gate^^ 
network «0. Otherwise, the transaction «.uld be tZ sane 

Flow C!^ai-t-p 

the d.«. """"^ '^^^ following figures use 

the designatxons ~A- and «B" to indicate two interacting 
trusted agents 120. The same designations A and B, may als! 
be applied to the host processor 124 or money module s 
assocxated with a particular trusted agent 120 (i e., withil 
the same transaction device 122) . The flow charts indicate 
the functional component primarily responsible for carrying 

Ih'/^>f ^^^^^ "^^^ A -an! 
that the recxted task is carried out by the Security Manager 
functxon 144 (see figure 4A) in trusted agent A 

„h^ H "^^ """^"^^ ^^^^ subroutines som^ of 

whxch use parameter designations X and Y. For example 
ESTABLISH SESSION A ^ B is a call to ^v, 
Est-av.n=v o . o IS a call to the subroutine 

ItTt . . '^^ ^^'^''^^ ^^-^ «^ould 

then be followed with the understanding that X - A and Y - 
B throughout the flow. 

■ . / °^ "e type conten,plated 
it is desir^le to pass *ectronic items such as tickets 8 
and electronic notes between two parties, while ,«intainlng 
a zero-sum game. l„ oaer words, it is undesirable t! 
duplicate electro nic -agtlSW at the completioro^ t 
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electronic transaction there are twice as many items as 
before the transaction. Similarly, it is undesirable to 
lose electronic items so that there are fewer items after 
the transaction than before. For example, if at the start 
of a transaction A has an electronic ticket 8 and wishes to 
5 pass it to B, then it is desirable to ensure that at the end 
of the transaction, B has the electronic ticket 8 and A does 
not have the electronic ticket 8. In the real world, 
however, it is possible to have two other outcomes, namely, 
both A and B have the same electronic ticket 8 (duplication) 

10 or neither A nor B have the electronic ticket 8 (loss) . 

In order to render the likelihood of duplication 
or loss negligible, the transaction protocol must take into 
account the possibility that natural or intentional events 
may interrupt a typical transaction flow. 'a natural 

15 interruption is exemplified by a breakdown of the 
communications link between A and B during the transaction. 
To minimize the possibility of duplication or loss from such 
a random event the window of opportunity for creating a 
duplication or loss must be minimized. In order to minimize 

20 intentional interruptions (i.e., overt attacks), it is 
desirable to eliminate the economic incentive for such an 
attack. For example, if an attacker could only lose the 
tickets and or the money by trying to interrupt a 
transaction, the attacker would have no incentive to 

25 initiate the attack in the first place. 

These concepts are embodied in the efficient 
transaction protocols of the described system. In 
particular, it is desirable to ensure consistent sdoort and 
commit states between the two transacting trusted agents 120 

30 (or money modules 6) . For example, if A commits to a 
transaction, then B should also commit to the transaction; 
or, if 'a aborts the transaction, then B should also abort 
the transaction. To achieve consistency and minimize the 
possibility of duplication or loss (in the event there is an 

35 inofdlist'Qblsilby) the trar^^actir- protocols take into account 
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the order and timing of A'b and B'b connnitting to a given 
transaction. ^^^^ 

Figure 6 shows two subroutines. Abort and Coitmdt 
The abort subroutine is internally executed within a given 
trusted agent 120 when the transaction it is involved in 
faxls The abort subroutine rolls back or returns the 
trusted agent 120 to the exact state it was in prior to 
bexng xnvolved with the failed transaction. In addition, if 
the merchant trusted agent aborts after an authorization, 
then the authorization will be reversed. Conversely the 
commit transaction is internally executed within a given 
trusted agent 120 when the transaction it is involved in has 
been successfully completed. The trusted agent 120 
therefore records the completed transaction in its 
transaction log and is now ready for a new transaction. For 
example, during a ticket transfer transaction an electronic 
ticket 8 is passed from trusted agent A to trusted agent B 
Sxnce at this point in time neither A nor B have committed 
or aborted the transaction. A provisionally retains the 
ticket 8 while B provisionally also has the ticket 8 If 
both A and B commit then A will delete its ticket 8, and B's 
retention of the ticket 8 will no longer be provisional. 
If, however, both A and B abort then A will retain its 
ticket 8 and the ticket 8 that B was retaining provisionally 
wxll be deleted by rolling back the transaction. Note that 
the deletion operation may be implemented in various ways 
well known in the art. As mentioned before, it is desirable 
to minimize the possibility of one trusted agent 120 
committing while another trusted agent 120 aborts because 
this may in some limited circumstances result in duplicating 
or losing electronic items. 

A similar situation exists with respect to money 
modules 6 exchanging electronic notes. During a purchase 
transaction, electronic notes are passed from money module 
A to money module B, so that A provisionally decrements 
electronic notes (by the amounts transferred) whil 
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** provisionally has electronic notes (in the transferred 
amount) . If both A and B commit then A will retain the 
notes in the decremented amounts and B's retention of the 
electronic notes will no longer be provisional. 

Figure 6A shows the commit subroutine. Tran Log 
5 X updates the transaction log. To Host X notifies the host 
that the trcuisaction is complete « Session Manager X notes 
the end of the session. (Steps 230 - 234) . 

Figure 6B shows the abort subroutine. Session 
Manager X rolls back changes and notes agent aborted. The 
10 Session Manager keeps track of what has been done since the 
start of a session and when rolling back undoes these steps. 
To Host X sends a message to the host that the txransaction 
is aborted. (Steps 236 - 238) . 

The abort subroutine may be called directly from 
15 a flow diagram, for example, when a trusted agent 120 
detezmines that a certificate is not valid. The abort 
subroutine may also be called when an esqpected action does 
not occur. In particular, when two trusted agents 120 are 
communicating, they will be monitoring a time-out protocol. 
20 For example, after a first trusted agent 120 has sent a 
message to a second trusted agent 120, the Session Manager 
of the first trusted agent (A) will set a timer for a reply 
if a reply is required. The Session Manager may also number 
the message sent. This nuniber would appear in the reply 
25 message from the Session Manager of the second txnisted agent 
(B), 

If the timer expires before the message has been 
received, then Session Manager A will gu^ry Session Manager 
B to determine if the transaction is still running in B. If 

30 B does not reply then Session Manager A will abort the 
transaction. If a reply is received that the transaction is 
proceeding, then the timer will be reset to a new time. If 
A queries B a predetermined niimber of times without 
receiving a reply to the original message, then A will abort 

35 the transaction. A similar time-out fu^iStlSff^iei^sts in the 
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money modules 6 . 

Figure 7 shows the flow chart for an 
authorization-based purchase/sale of electronic money, when 
the owner of a trusted agent A wants to buy or sell 
electronic money by debiting or crediting his bank account 
he uses a transaction application in his CTD 188 to shop the 
merest networks X34 for the lowest merchant transaction 
fee and/or exchange rate and selects, in this example, the 
merchant owner of trusted agent B (steps 700 - 702) . it may 
be noted that, alternatively, the authorisation netw^k 
could set the exchange rate. "ecworK 

Host transaction application A (HTA) then connects 
to host transaction application B (HTB) , whereupon the 
customer chooses the type of transaction, namely a purchase 
or sale of electronic money (step 704) . HTA sends a message 

^'se^nds™''" ^ ''"^ ^^^^^---'<^ -ney, a!d 

HTB sends a message to its trusted agent B to send (receive) 
exectronic money (steps 706 - 70B) 

The customer's and merchant's trusted agents (A 
and Bl then establish a session as described In co-pending 
U.s application oe/a34.461. m particular, an Establish 
session subroutine is called (step 710) for setting up a 
cryptographlcally secure communication channel bet,;en^ 
trusted agent A and trusted agent B. Referring to Figure e. 
the session M««ger of trusted agent A re».estB and then 
re«l.es A's certificate (I.e.. cert(TA„ from the Securl ^ 
Manager (steps 296 -298) . session Manager A then sendl 
certlTA, to trusted agent, B-s .Session Manager which. In 
turn, passes it along to its Security Manager (steps 300 - 

. J"""* *3ent B'slsublic Key function verifies the 
certfTA, by using the validation protocol, such as those 

^/nnt^r""*"""" - Oe/234.461 and 

08/427,287 (steps 306 - 308). 

If cert (TA) is n^^id,; then Session Manager B 
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O 

notes that the session is terminated and informs Session 
Manager A that the trajisaction is denied. Session Manager 
A also notes that the session is terminated. (Steps 310 - 
312) . If cert(TA) is valid, then Security Manager B checks 
if tmsted agent A is on the imtrusted list (st^s 314 - 
5 316) , If trusted agent A is untrusted, then the session is 
terminated (steps 310 - 312) • 

If A is not on the untrusted list, then Random 
Number Generator B creates a random number R(B) and also a 
B verification message (step 318) . The random ntuhber R{B) 
10 will eventually be used to form a session key. The B 
verification message is a random number used by B to protect 
against message replay. Next, Security Manager B assembles 
R(B), the B verification message, and cert(TA) into a 
message for trusted agent A (step 320) . Public Key B 
15 encrypts the message using trusted agent A's public key 
(TA(PK)) which trusted agent B received with A's cert(TA) 
(step 322) . Session Manager B sends the encrypted joessage 
to A's Session Homager (steps 324 - 326). 

Public Key A decrypts the message xtsing its 

20 private key (corresponding to its public key) and verifies 
the validity of cert(TA) (steps 328 - 330). If cert(TA) is 
invalid, then Session Manager A notes the session as 
terminated and sends a transaction denial message to B whose 
Session Manager also notes the session as terminated (step^ 

25 332 - 334). If cert (TA) is valid, then Security Manager A 
checks if trusted agent B is on the untrusted list (steps 
336 - 338) . If trusted agent B is on the list, the session 
is teoainated (steps 332 - 334) . 

I^ B is not on the untrxisted list, then Random 

30 Number Generator A creates a random number R(A) and an A 
verification message (e.g., another random number) (step 
340) . The iDate/Time function passes the current date and 
time to the Security Manager (step 342) . Dates and times 
are exchan^^d by A and B for eventual recording in their 

35 trans ^l^b^s^iffilbg commits. Security Manager A then forms 
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and Stores session key ^Ct^TA) by exclusive ORing random 
numbers R{A) and R(B) (steo 344 > e«=»- 

* • P 344}. Session key (TA/TA) is 

used to encrypt communications between two trusted agents 
120 session Manager A assembles a message containing the 
A and B verification messages, the date/time information, 
andR(A) (step 344). Public Key A encrypts the message with 
trusted server B's public key (received by A in cert(TA)) 
and sends the encrypted message to trusted server B's 
Session Manager (steps 346 - 350) . 

Public Key B decrypts the received message using 
xtB secret key (corresponding to its public key) (step 352) 
security Manager B checks if the B verification message 
received from A is the same B verification message it 
previously sent to A (steps 354 - 356) . if it is not the 
same, then the session is terminated (steps 310 - 312) if 
it IS the same, then Session Manager B notes the start of 
the eesBion (step 358) . 

security Manager B forms session key (TA/TA) by 
R A XOR R(B) and then stores the session key (step 360) 
At this point, both A and B have created and stored the same 
session key (i.e., session key (TA/TA)) to be used for their 
current interaction. Next. Date/Time B sends its current 
date and time information to Security Manager B (step 362) 
security Manager B assea^les a message having an 
acknowledgement to A, the A verification message, and B's 
date/time information (step 364). The Send Message 
subroutine is then called (step 366) for sending the message 
from B to A. ^ 

Referring to Figure 9 , trusted agent B ' s Symmetric 
Key function encrypts the message using session key (TA/TA) 
(step 376). Message Interface B then formats the message 
and sends it to the host processor's Message Manager (step 
378) . Host Message Manager B then routes the message via 
communications to Host Message Manager A in trusted agent 

^S^^^^^irtl '"""^ • Manager A then 

^S.-^.^ends the message to trusted agent A's Message Interface 
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which Strips out the message (steps 382 - 384), Symmetric 
Key A decrypts the message with session key (TA/TA) thus 
completing the secure communication of a message between 
trusted agent and trusted agent using session key (TA/TA) 
(step 386) . 

5 Referring again to Figure 8, Security Manager A 

receives the acknowledgement, A verification message and B's 
date/time information (step 368) . Security Manager A checkfs 
if the A verification message is the same A verification 
message which A previously sent to B (steps 370 - 372) . If 

10 it is not the same, then Session Manager A terminates the 
session (steps 332 - 334) , If it is the same, then Session 
Manager A notes the start of the session (step 374) . 

Referring again to Figure 7, after establishing a 
session, trusted agent A recjuests and checks the merchant 

15 credential of trusted agent B, also as described in U.S. 
application 08/234,461. In particular, referring to Figure 
10, the Check Credential subroutine is called (step 712) . 
All MTDs 198 contain a credential identifying the 
owner /merchant (e.g., NYNEX, Ticketron, etc.). Such 

20 merchant credentials may, for example, be issued by a 
merchant identification authority controlled by the Trusted 
Agency, On the other hand, customer credentials held by 
CTDs 188 may include driver's licenses or credit cards 
issued by various identification authorities. Referring to 

25 Figure 10, Purchase A sends a message to Purchase B of 
trusted agent B requesting its merchant credential (steps 
444 - 448) . Ticket Holder B retrieves its merchant 
credential and sends the credential to A for validation 
(steps 450 - 456) . 

30 Credentials or any other type of ticket 8 are 

validated as follows: 

1) Validate issuer certificate and check issuer 
signature . 

2) Verify each transfer - match receiver and 

35 sender identifiers (i.e., S^ «= Issuer^ = """^^ ^ 
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3) 
4} 



1st receiver, then R, = s,^,, i>o) . 
Validate each sender certificate and check 
each sender signature. 

verify that the laBt receiver Identifier 
inatoheB the identifier (TA(id) ) of the 
certificate (eert(TA)) of the trusted agent 
in the current sesBion. 

If the merchant's credential is not valid, then 

"^"^ "'"^"^ '"^ TranaLction 
euhroutxne (atep 4S8) . Referring to Figure ix, truBted 
^ent A aborts (step 3,3, and its Session Manage; sZds a 

that A has Shorted (step. 390 - 39.) . Trusted agent B then 
aborts (step 3,6,. Referring back to Figure 10, if 
-r^fs credential is valid, then To Host A .ends th: 
"fo--"- to a host transfer application for 

^ ^ °' merchant na,.« by 

CTD holder) (steps 4eo - 462) 

Referring again to Figure 7, the flow for the 
purchase/sale of electronic money continues. To Host I 
revests the amount of electronic money and in which 
monetary unxt (e.g., dollars, yen, pounds, etc.) it wishes 
to buy or sell (step 714) . The customer or a surrogate 
process enters this information which is receiver by 
Purchase A and sent to trusted agent B (steps 716 - 716) 

Purchase B receives the message and checks if it 
IS to receive electronic money (steps 720 - 722) . if so 

c^itVT! ! """"^ '° """"^ requesting a ban; 

credit or debxt credential (steps 750 - 752) . Ticket Holder 
A receives the message and sends ,a list of possible 
credentials to HTA (step 7S4, . A cre^itial is picked a^l 
the choice IS sent to the trusted : agent A (step 756) 
Txcket Holder A then retrieves the selected credit or debit 

T^:Tl'l\.r """" * "^^^'^^ B 
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Purchase B then validates the credential as 
described previously (steps 764 - 766) , If the credential 
is not valid, then the transaction is aborted. If it is 
valid, then Ticket Holder B creates an electronic money 
purchase receipt, and Purchase B sends the receipt to 
5 trusted agent A (steps 768 - 772) . 

Purchase A receives the receipt suid checks if it 
is valid (steps 774 - 776), If not valid, then the 
transaction is aborted (step 778) . If it is valid, then 
Purchase A sends receipt information to the HTA for 
10 purchaser confirmation (steps 780 - 782) . If not confirmed, 
then the transaction is aborted, otherwise. Purchase A sends 
the receipt to Ticket Holder A (steps 784 - 786) . 

Purchase A then sends a message acknowledging 
receipt to trusted agent B (steps 788 - 790) . Purchase B 
15 then checks if electronic money is to be received (steps 792 

- 794) . If so, then To Host B sends a message with amoxint 
and credential to the card authorization network 208 to 
credit the bank accoimt identified by the credential (step 
796) . Following the card authorization process (step 798) , 

20 Purchase B checks if the credit was authorized (steps 800 - 
802) . If not, the transaction is aborted, otherwise 
Purchase B sends a message to trusted agent A that the 
credit was authorized (steps 804 - 806) . 

Trusted agent A then performs a money module 

25 payment to trusted agent B as described in U.S. application 
08/234,461. In particular, a Money Module Payment sub- 
routine is called (step 808). Referring to Figure 12, 
Random Number Genera|:or ,A creates rcuidom number R(l) (step 
520). Purchase A then sends a message to trusted agent B 

30 indicating that a^"nibney module payment" will be made and 
also containing R(i) Metep 522 - 524) . Purchase B receives 
the message and sends R(l) to Security Manager B (steps 526 

- 528) . Random Number Generator B creates random number 
R(2) and sends it' tb ttusted agent A (steps 530 - 532). 

35 Security Managei?§%%HS^%^^b^ form session key (TA/MM) by 
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exclusive ORing R(i) and R(2) (steps 534 - 535) 
.n.^.- ^«f«"^ing to Figure 13, there is shown four 
encryptxon channels established during a transaction 
Encryptxon Channel 436 between the two trusted agents 120 
carrxes messages encrypted by session key (TA/TA) . Channels 
438 and 440 between a trusted agent 120 and its money module 
6 share session key (TA/MM) . Channel 442 between money 

session key (TA/MM) is used for encrypting 
messages sent between a trusted agent 120 and its associated 
money module 6 via encryption channels 438 and 440. ^At the 
present point in the flow diagram, only the two trusted 
agents 120 have session keys (TA/MM) . Both money modules 6 

(TA/MM) so as to enable encrypted communication between the 
trusted agents 120 and their money modules 6. 

It may be noted that instead of the trusted agent 
120 and money module 6 being embodied as discrete tamper- 
proof components, they may be fabricated as one tamper-proof 

est^l- H ^ to 

establxsh a secure session for communication between trusted 

agent 120 and money module 6 in the same transaction device 
122. However, discrete money modules 6 and trusted agents 
120 are preferable in that such a configuration allows for 
greater application flexibility. 

Referring back to Figure 12, To Money Module A 
sends a -Make Payment" message and R(i, to its associated 
^ 5«dule A. Also, To Money Module B sends a -Receive 
Payment- message and R(2) to its associated money module B 
(steps 538 - 544). 

., - ^^'S^' ""^y ""dule A (within the CTA 2) 

«d. Boney module B (within the MTA 41 establish e session 
betwe» then so that each money ,»aule 6 wimis up holding 

.'Sli^rT ""' in establishing thl! 

to nonay module session, the money modules 
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exchange messages via the pre-existing trusted agent's 
session. Referring to Figure 13, the session key for 
encryption channel 442 is formed by exchanging messages 
encrypted by channel 436, After the money module session is 
established, messages sent between money modules will be 
5 encrypted twice, by both session key (MM/MM) and session key 
(TA/TA) , along the portion of the communication path between 
trusted agents 120. 

In the preferred embodiment, the money module 
session is established in a manner similar to the 
10 establishment of a trusted agent session. The money modules 
6 would therefore hold their own certificates containing 
their public keys. The swapping of certificates and random 
numbers (for XORing) enables the secure creation of session 
keys (MM/MM) . The Establish Session protocol used by money 
15 modules is described in U.S. application 08/427,287 and is 
shown in Figure 14. Maintain Security A sends the module 
certificate to the session manager, and Session Manager A 
receives the certificate and checks if money module A is 
connected to the network (steps 1464 - 1466) . If money 
20 module A is not connected to the network, then Session 
Manager A sends the certificate received from Maintain 
Security A to destination B (step 1476). 

Alternatively, if money module A is connected to 
the network, then Symmetric Key A encrypts the certificate 
25 with K and Session Manager A sends the encrypted certificate 
to the network server (step 1468 - 1472) . The Network 
Server decrypts the certificate with K and sends the 
certificate to destination B. 

Regardless of whether the certificate was sent by 
30 the Network Server or by Session Manager A, Session Manager 
B receives the certificate and Maintain Security B (if B is 
a security server, then this function is performed by the 
Session Manager) validates the certificate (steps 1480 - 
1482) . If the certificate is not valid, then Session 
35 Manager B notes the session is terminated and informs either ^ * 
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the subscrii^r or the bank (steps i486 - 1492) (if b is a 

If the certificate is valid, then Maintain 

1496) . If A xs on the list, then the session is terminated. 
If A xs not on the list, then Random Number Generator B 

ZIT^.IT"" ""^'^ " ^ verification message 

step 1498) . Cloclc/Timer B retrieves the time and date 
(step 1500). Maintain Security B asse„.>les R(B) B 
yerxfxcation message and time and date in a message (step 
1502) Public Key B encrypts the message with A'! XZ 
key and Session Manager B appends B's certificate to the 
encrypted message and sends the message to A (steps 1504 - 

1506) . 

A . recei^res the message , Public Key 

A decrypts the encrypted part of the message, and Maintain 
Securxty A validates B's certificate (steps 1508 - 1514) 
If the certificate is not valid, then Session Manager A 
notes the termination of the session and informs either the 
subscrxber or the bank (steps 1516 -1522). if thi 
certificate is valid, then Maintain Security A checks if B 
xs on the bad id list (steps 1524 - 1526) . if b is on the 
Ixst. then the session is terminated. if b is not on the 
Ixst, then Maintain Security A retrieves the date and time 
and compares it to B's date and time (steps 1528 - 1530). 
I£ the date and time are out of ranae t-h«n 
terminated. ^ ' ""^^ ^^^^^^'^ " 

Number r " T ^^""^ range, then Random 

Number Generator A creates random number R(a) and an A 
verxf xcation message (step 1532) . Maintain Security A then 
forms a session key by the operation R{A) XOR R(B) (step 
1534) . The A verification message, the B verification 
message, the time, date and R(A) are assembled into a 
message and encrypted with B's public key (step 1S36), The 
message is sent to B by Session Manager ;.J^^:335^^ 
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° Session Manager B receives the message. Public Key B 
decrypts the message and Maintain Security B checks the B 
verification message (steps 1540 - 1546) . If the B 
verification message is incorrect, the session is 
terminated. If the B verification message is correct, then 
5 Maintain Security B forms the session key by R(A) XOR R{B) 
(step 1548) . The time and date are retrieved and compared 
to A's time and date to check if they are within a 
predefined range of each other (step 1550) . If the time and 
date are out of range, then the session is terminated. If 

10 the time and date are in range, then Session manager B notes 
the start of the session (step 1552) . 

Session Manager B then sends an acknowledgement 
and the A verification message to A (steps 1554 - 1556) . 
Session Manager A receives the message and Maintain Security 

15 A checks the A verification message (steps 1558 - 1562) . If 
the verification message is not correct, the session is 
terminated. If the verification message is correct, then 
Session Manager A notes the. start of the session (step 
1564) • 

20 The overall system security pertaining to the 

money modules may be integrated with that for the trusted 
agents 120, but is preferably separate to provide for 
enhanced system security and system flexibility. 

Referring back to Figure 12, money module A sends 
25 R(l) to money module B. This function may be initiated by 
a MM Maintain Security A application residing in money 
module A (step 548) . This application and other money 
module applications are^ prei^^^i^d by the designations "MM" 
and are described in commonly assigned U.S. patent 
30 application 07/794,112 together with any modifications 
and/or additions disclosed iii^tJ.S. application 08/234,461. 

Random number R(l) fs sent from money module A to 
money module B by the siibroutine Send Routed Message (step 
550) . Referring to Figure 15^ MM Symmetric Key A encrypts 
35 the message (including *i^t1^^^^^ (MM/MM) (step 
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640) . MM 



10 



Session Manager A sends the message to Host 
Message Manager A which, in turn, sends the message to 
Message Interface A of trusted agent A (steps 642 - 646) 
Trusted agent A then sends the message to Message Interface 
B of trusted agent B using the Send Message subroutine (step 
648) which encrypts and decrypts the message with session 
key (TA/TA) in between the trusted agents. Message 
Interface B then sends the message to MM Session Manager B 
xn money module B via Host Message Manager B (steps 650 - 
654) . Finally, MM Symmetric Key B decrypts the message with 
session key (MM/MM) (step 656) . 

Referring again to Figure 12, MM Maintain Security 
B (m money module B) forms session Icey (ta/MM) by exclusive 
ORing R(i) and R(2) . Money module B then sends R(2) to 
money module A which also forms session key (TA/MM) by 
exclusive ORing R(i) and R(2) (steps 552 - 556) . Referring 
to Figure 13, at this stage, three session keys exist- 
(MM/MM) , m/TA) , and (TA/TA) . Thus, the four encryption 
channels shown are in place. 

Referring to Figure 12, MM To Subscriber A prompts 
trusted agent A for the amount of payment by type of note 
(e.g., dollars, yen, pounds, etc.) (step 558). a money 
module as described in U.S. patent application 07/794,112 
incorporated by reference herein, would generally use the To 
subscriber application for communication with the 
25 owner/holder of the money module. However, as used in the 
present instance, the To Subscriber application communicates 
with the trusted agent 120 for getting various instructions 
per^,, *he trusted agent 120 delivers amount of payment and 
type of note information (trusted agent A has previously 
communicated with the owner/holder of the CTD 2 to determine 
the amount) . 

The prompt from the money module 6 to the trusted 
agent 120 is sent via the Send MM/TA Message subroutine 

''^^^"'^"^ ^° ^^9^^^ MM symmetric Key A 

the message with session key (TA/MM) (step 658). 
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MM Session Manager A sends the message to trusted agent A's 
Message Interface via Host Message Manager A {st^s 660 - 
664) . Symmetric Key A decrypts the message with session key 
(TA/MM) (step 666), Referring back to Figure 12, Purchase 
A of trusted agent A sends the amount (price of selected 
5 merchandise) by type of note to MM Pay/Exchange A of money 
module A (steps 562 - 566) . This message is sent via the 
Send TA/MM Message sxibroutine (step 564) . Referring to 
Figure 17, Symmetric Key A encrypts the message with session 
key (TA/MM) (step 668) . Message Interface A sends the 
10 message to money module A's MM Session Manager via Host 
Message Manager A (steps 670 - 674) . Finally^ MM Symmetric 
Key A decrypts the message with session key (TA/MM) (step 
676) • 

Referring to Figure 12, MM Note Directory A checks 

15 if the money module 6 has sufficient fimds to cover the 
payment (steps 568 - 570) • If insufficient, then money 
modules A and B abort the transaction (steps 572 - 582) . 

The MM Abort transaction protocol (step 582) may 
be that of the preferred electronic monetary system as 

20 described in U.S. application 08/427,287 and shown in Figure 
18, Session Manager X rolls-back changes and notes that the 
transaction is aborted (step 1726) . Session Manager X then 
checks if the "Ready- to -Commit" message has been sent (steps 
1728 - 1730) . If so, then X updates its transaction log 

25 (step 1732) by recording that X committed after sending a 
Ready-to-Commit message and recording the note identifiers 
and amoxints of each note received during the Transfer Notes 
protocol. Thus, the abort protocol logs information when 
the Abort subroutine is called during a failed Commit 

30 subroutine . 

If X is a transaction money module 1186, and the 
Ready- to-Coramit message was sent, then To Subscriber X 
informs its subscriber that the transaction was aborted and 
that there may have been a money transfer error (steps 1734 

35 - 1738) . 
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If X is a teller money module 1188, then To Bank 
X xnforms the bank that it should reverse its accounting 
transactions (by appropriate debits and credits) (steps 1740 

- 1742) . If X is a transaction money module 1186 and no 
Ready-to-Commit message has been sent, then To Subscriber X 
(stin744T. '"^''"'^"^ transaction was aborted 

m any event. Session Manager x then sends Y a 

T '"^^ -n^leted (steps 1746 

- 1748) . session Manager Y rolls-back its changes and notes 
the transaction as aborted (step 1750) . y then informs its 
subscriber that the transaction is aborted (steps 1752 - 

ZTL^' T"' ^""^ """^ '° """^"^ accounting 
transaction (steps 1756 - 1758) , 

AS described, if a transaction is interrupted 
during a commit protocol, it is possible that notes will be 
lost If this occurs, the transferee will have aborted and 
the transferor will have committed to the transfer of notes 
in this case, the transferee money module ^cords 
information about the notes it should have received and 
notifies the subscriber that there is a potential problem 
U.e. It did not receive the notes sent by A) . it may be 
noted that in this circumstance, as far as the transferor 
money module is concerned, it properly transferred the 
notes , 

The transferee money module subscriber can then 
make a claim for the money to the Certification Agency. The 
claim information would include the log record of the failed 
transaction. The Certification Agency could then check with 
issuing banks to see if the notes have been reconciled. 
After some period of time, if the notes have not been 
reconciled, the subscriber could reclaim his money. 

Referring again to Figure 12, the messages between 
money module A and money module B are sent via a Send B- 
Routed Message subroutine which utilizes all three session 
keys (MM/MM) , (TA/MM) , and (TA/TA) . Itefe^in^STIi^ If 
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MM Symmetric Key A encrypts a message with session key 
(MM/MM) (step 678) . The message is then doxible encrypted by 
session key (MM/TA) before it is sent to trusted agent A. 
Once received by trusted agent A, the message is decrypted 
by session key (MM/TA) . (Step 680) . Message Interface A 
then sends the message to Message Interface B (steps 682 - 
684) . In between trusted agents 120, the message is double 
encrypted by session key (TA/TA) . In like manner. Message 
Interface B sends the message to MM Symmetric Key B for 
final decrypting (steps 686 - 690) . Figure 13 illustrates 
the various encryption layers. 

Referring again to Figure 12, during the abort 
routines of money modules A and B (step 582) , they generate 
messages sent to their trusted agents A and B, respectively 
(steps 584 - 586) informing them that they have aborted the 
transaction and hence that payment was unsuccessful. 
Session Managers A and B note that the payment was 
unsuccessful and consequently trusted agents A and B abort 
(steps 588 - 598) . 

If, on the other hand, the customer's money module 
2 has sufficient funds then MM Pay/Exchange A sends a 
message to the merchant's money module containing the amount 
of money to be transferred in payment and the type of notes 
(step 600) . This message is sent by the Send E-Routed 
Message subroutine (step 602) * 

Money module B receives the message containing 
the payment amount according to money module A. MM To 
Subscriber B then sends a prottpt to trusted agent B to 
verify this payment amount (8tepp^6p$ - 606) . Accordingly, 
Purchase B in trusted agent B verifies if the amoxint is 
correct (steps 608 - 610). If correct, then trusted agent 
B sends a "Correct Amount" message to money module B. If 
incorrect, then an "Incorrect Amount" message is sent. 
(Steps 612 - 616) . In the event of an "Incorrect Amount" 
message, money module B informs money module A which, in 
turn, requests its trusted adf^t^^«fMSsend a new amount or 
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elBe abort (steps 618 - 622, 572 - 582). In .noney module 
payments made during an electronic merchandise purchase, the 
truated agent will not send a new amount and hence both 
money modules 6 and both trusted agents 120 will abort. 

If, on the other hand, money module B receives a 
-correct Amount" message from its trusted agent, then money 
module B sends an Acknowledgement message back to the 
customer's money module (steps 624 - 626). when mm 
Pay/Exchange A receives the Acknowledgement message, it then 
passes the amount to Money Holder A (the application which 
contains and manages the electronic representations of 
money) (step 628) . 

Note that the payor initiated protocol just 
described may instead be implemented as a payee initiated 
payment as in the POS Payment protocol, m such a protocol 
the merchant's trusted agent instructs its money module as 
to the payment amount it expects to receive, this payment 
information is sent to the customer's money module which 
prompts its trusted agent for verification, and if the 
amount is correct, then the customer's trusted agent informs 
Its money module. 

Referring again to Figure 12 , the customer' s money 
module A then transfers electronic notes in the amount 
specified to the merchant's money module 4 via the E-Routed 
message path (step 630) . Figure 20 shows a Transfer Notes 
protocol as described in U.S. application 08/427,287. Note 
Directory X chooses the note(s) and values for transfer 
updates the note amount (s) and sequence number (s), and then 
sends the message t^o.Notes (step 1566) . Possible objectives 
in choosing the. nptes for transfer may, for example, be: 
30 (1) minimize the number of digital signatures (which 
requires processing^ time) , (2) minimize the size of the 
packet; (3) maximize the usefulness of the electronic notes 
left to the transferring subscriber (i.e., pass the notes 
with the «»^ortesJ time left until expiration). Such 
' ^"^iectives ;»n a^^j^^ d by the following note transfer 
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algorithm: (1) determine all possible alternatives which 
contain the least number of notes; (2) determine which of 
these alternatives have the least number of transfers; (3) 
if more than one choice is left from step 2, choose the one 
which has the least number of monetary unit days • Monetary- 
unit days = residual value of note to be transferred times 
the number of days left until the note expires, summed for 
all the notes in the packet. 

Notes X, upon receiving the message from Note 
Directory X, creates a transfer to be appended to each note 
being transferred (step 1568) . Pxiblic Key X creates 
signatures for the note(s) (step 1570). Packet Manager X 
then assembles the note(s) with their new transfer (s) and 
signature (s) in a packet and sends the packet to Y (steps 
1572 - 1574) . Packet Manager Y receives the packet and 
disassembles it (step 1576) . 

Verify Y validates all certificates in the note(s) 
(e.g., money generator certificate and all transfer 
certificates) . Then Verify Y verifies that the 

identification numbers in the transfer group match up with 
the module identification numbers of the certificates in the 
signature and certificate group throughout the history of 
the electronic note. Also, the consistency of the transfer 
amounts for each note is validated by ensuring that 
throughout the electronic note history the amount 
transferred in each successive transfer is less than that of 
the immediately precedent transfer. In addition, the total 
amount transferred is checked to ensure it is the amount 
expected. (Steps 1578 - 1580) . If not valid, then the 
transaction is aborted (step 1582) . 

If valid and Y is a transaction money module, then 
Verifier Y verifies the expiration dates of the note(s) 
(steps 1584 - 1588). If any of the note(s) have expired, 
then the transaction is aborted. If none have expired, then 
Verifier Y checks each id from the note transfers against 
the bad id list (steps 1590 - 1592) . If any of the transfer 
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Id's are on the bad Id list fh-- ^ 

aborted. ' transaction is 

If the transfer id's are not on the bad id list 
(or Y is not a transaction money module), then Public Key y 
verifies the validity of th» nnf. /.I • <iuj.ic ney i 

5 - 1B961 Tf . . . ' ' signatures (steps IS94 

1596) If any of the signatures «^ not valid, then the 
transaction is aborted, if the signatures are vlua t^ 
verifier V cheCcs if the note.s, bodies match note i^T^s 
that „e stored by the »otes application or located in th: 

10 !T. ' " ""^ -^e body that 

10 matches, a note transfer tree is created in orler^o 

1 ™ oTr'^L"'-" ^"P"«tion (step 

1602 1604). If any of the notes have been duplicated 
then the transaction is aborted. This cheCc for du^licatlo; 

.5 ^ll" -""-l^ly directed to, and 

15 well suited for. thwarting individuals who attempt to create 

-ney by transferring notes by -self -dealing! J^'l 

coni>romised transaction money module. 

note h„H- " "° duplicates, or if no matches of 

note bodies were identified, then Notes V places the note(s) 
in the money holder (step 1606) . Pinally. „ote Directory Y 
upd. es the note,s) location(s) and amount <s), and aul 
initializes sequence number(e) (step 1608). 

It may be understood that the Transfer Kotei 

25 sZ" -^^^ initialising : 

seguence nu„.«r to facilitate note reconciliation, checfing 

cL^ °' °» the bad id list, ax^ 

Checking for note duplication, these additional features 

"Lulir T," """^^ adversaries to introduce and 
circulate duplicated notes, and enhance the ability to 
30 detect duplicated notes in circulation. 

Referring back to Pioure t5 , ... 

subroutine is called (step 632) TT !' 

-i, . . ■ protocol as used 

in the preferred electronic monetary system is described in 
U.S. application 08/427.287 and shown in Pij^re 21. session 
35 Manager X sends a .Ready-to-Oommif mes^^y ,eteps 1702 
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- 1704) . This passes the obligation to commit to the module 
receiving the message. In a conventional money transfer 
scenario, this technique of passing the burden of committing 
first is used to ensure that the party transferring money 
commits first, so as to eliminate the possibility of 
5 duplicating money. 

Session Manager Y then sends an acknowledgment to 
X (steps 1706 - 1708) and commits to any outstanding 
transactions by updating its transaction log (step 1710) . 
Also, if Y is a transaction money module, then To subscriber 

10 Y notifies the subscriber of the successful transaction 
(steps 1712 - 1714) . Session Manager Y notes the end of the 
session (step 1716) . 

Tran Log X receives the acknowledgement from Y and 
updates its transaction log, thus committing to any 

15 outstanding transfers. X completes its commit in the same 
manner as Y (steps 1718 - 1724) . 

This flow diagram is still followed when money 
modules 6 are interacting with trusted agents 120 with the 
understanding that Send Message « Send E- Routed Message and 

20 that To Subscriber messages are actually sent encrypted to 
the trusted agent 120. With the foregoing in mind, money 
module B's MM Session Manager sends a "Ready-To-Commit" 
message to money module A's MM Session Manager via the ©end 
E-Routed Message siabroutine (steps 1702 - 1704) . MM Session 

25 Manager A then sends an "Acknowledgement" message to money 
module B and money module A commits (steps 1706 - 1716) , 
When money module B receives the "Acknowledgement" message 
it too commits (steps 1718 • 1724) . 

During the commit routines of money modules A and 

30 B, they generate messagi^s sent to their trusted agents A and 
B, respectively (stepis 1714, 1722) informing them that they 
have committed to the trahsaction and hence that the payment 
was successful. 

Referring again ^o Figure 12, the money modules 

35 then both send -tlie^^^i^irtentioned "Payment Successful" 
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meBsages to their trusted agents (stqie 5M - 58«) . Ttoee 
messages are encrypted by session key ,tv»I) . Session 
Manager A detects that a successful pay,«nt has been 

xnf ormatxon such as the date of transaction (steps see. 
634) . Trusted agent A then conmits (step 636) so chat its 
retention of the ticKet is no longer -provisional' 
S.m.l.rly, Session Manager B detects . successful p^ent 
(Bteps 590, 594) and trusted agent B co«its (step 
The transaction is now complete. ' 

Referring bacic to Pimira -7 n,. 

J. . , rj-gure 7, the previous 

dxsoussxon described the situation where a custcj wish^I 

Purchase B queries the money ,«>dule for suf fici«,t fund^ 

n»«- : I"' ■ " "» 
insuffxcent funds, then To Host B requests guidance from 

the host Which checcs if other of the merchantrtransLl:: 

dev«es have the requested amount (steps 728 - 732) If 

aevxce (havxng a Host c) to send money (step 734) . » 
session is established between 0 and B and a money .^ule 
^yment « ™ade (steps 736 - 738) . it n«y be noted that in 
th.s scenario there is no ticket as indicated in step 634 of 

zrz,T:z^:- --^^ - -pped 
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u ° ""^^ sufficient funds, then Host B 

checl^,if xt can withdraw the amount from a bank where it 

30 A withdraws electronic money from the bank (step 748) using 
the^ money generator module 202, teller module 204, and 

H^lrt . electronic money can be withdrawn, then 



At the point where the merchant has sufficient 
funds to distribute to the customer, the transaction 
proceeds as described in steps 750 - 794. To Host B then 
sends a message with the amount and credential to the card 
authorization network 208, to debit the bank account 
identified by the credential (step 810) . The card 
authorization process proceeds (step 811) and Purchase B 
checks if the debit has been authorized (steps 813 - 815) , 
If not authorized, then the transaction is aborted, 
otherwise trusted agent B makes a money module payment to 
trusted- agent A completing the transaction (step 817) . 

In this disclosure, there is shown and described 
the preferred embodiment of the invention, it being 
understood that the invention is capable of use in various 
other combinations and environments and is capable of 
changes or modifications within the scope of the inventive 
concepts as expressed herein. 
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I Claim: 



1. A system for the open distribution of 
electronic money con?>riBing: 

a customer trusted agent; 

a first money module associated with said 
customer trusted agent that securely communicates with said 
customer trusted agent; 

^ ""^^^^t trusted agent that establishes a 

t^LM^'T""''^''^ ^^^^ 

trusted agent; 

a second money module associated with said 
merchant trusted agent that securely communicates with said 
merchant trusted agent, and that establishes a second 

z^r'"'"''" ™ ^'^^^ ^^^^ ^^-^ 

electron.. ^^^^^ ^^^^^^^ 

electronic money purchase information and an account 

credential to said merchant trusted agent, and said mlZ 

~: ::r ; ^^'"^ ^ ^^^^^^ — 

author. , . • '"'^''^ ^^"'^ ^^^"'^ an 

authorization network and initiates an authorization process 
using information from said electronic ™«„ 
inf™«,-- J . electronic money purchase 

information and said account credential; 

where upon receiving authorization, said 
merchant trusted agent initiates a transfer of electronic 

loduL ^^'^ "^''"'^ '"^^'^'^ ""'^ '^^^^ "'^'^^V 

.r.^ '"''^ °' «^i<* account 

credential is a credit or debit card ticket. 

3. The system of claim 1, wherein said customer 
trusted agent also provides electronic money sale 
information to said merchant trusted agent, which uj 
information from said electronic money sale inforraationi 
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said account credential in an authorization process, where 
upon receiving authorization said merchant trusted agent 
initiates a protocol where said first money module transfers 
electronic money to said second money module . 

4. The system of claim 1, where said merchemt 
trusted agent initiates the transfer of electronic money to 
said second money module from another commonly owned money 
module, and where said electronic money from said another 
money module is distributed to said first money module. 

5. The system of claim 1, wherein said second 
money module accesses a bank network of a bank providing 
electronic money, and withdraws electronic money from said 
bank for distribution to said first money module, 

6. The system of claim 1, wherein said receipt 
ticket includes said customer's bank ID, account number and 
authorization amount* 

20 7. A system for the open distribution of 

electronic money comprising: 

a customer tzxisted agent; 

a first money module associated with said 
customer trusted agent that securely communicates with said 
25 customer trusted agent; 

a merchant trusted agent that establishes a 
first cryptographically secure session with said customer 
trusted agent; 

a second money module associated with said 
30 merchant trusted agent that securely -bdnununicates with said 
merchant trusted agent, and that ;ieBtablishes a second 
cryptographically secure session with said first money 
module ; 

where said customer trusted agent provides 
35 electronic money sale i-'rorma' *ofi'afeiiJ*ife^a6count credential 
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to said merchant trusted agent, and Baid merchant trusted 
agent provides a receipt ticket to said customer trusted 
agent ; 

where said merchant trusted agent accesses an 

5 usinr'T" '"'''"'"^ authorization process 

usxng xnformatxon from said electronic money sale 
information and said account credential; 

where upon receiving authorization, said 
customer trusted agent initiates a transfer of electronic 

10 ZZe ^-"^^ ^^'^ ---- -ey 

8. The system of claim 7, wherein said account 
credential is a credit or debit card ticket. 



15 



9. 



tlni..^ • . "^^ °^ "^^^^^^ receipt 

ticket includes said customer's bank ID, account nurr^er, a^d 
authorization amount. 



20 10. A method for open distribution of electronic 

20 money utilizing a customer trusted agent, a first money 

module, a merchamt trusted aaent a«H » »^ ^ 

. iUBtea agent, and a second money module, 

comprising the steps of: 

. establishing a first cryptographically 

25 r T '"'^ ""^'^"^^ -^-t and said 

25 merchant trusted agent; 

(b) said customer trusted agent transferring 
purchase information and an account credential, via said 

^^^^^"f^^-^ — session, to said merchant 
trusted .ag^nt; 

^ , . ^^^^ merchant trusted agent creating a 

receipt ticket including, at least in part, said purchase 
information and said customer's bank account number; 

H ^ 4 ^^^^ merchant trusted agent transferring 

35 r ''"^ ™™cally secur! 

nnfi^i^f '^^^'^^^ ^^^^^ provisionally 
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retains eaid ticket; 

(^) said merchant trusted agent accessing an 
authorization network and initiating an authorization 
process using information from said purchase information and 
said account credential; 

(f ) estcdDlishing a second cryptographically 
secure session between said first money module and said 
second money module; 

(g) said second money module transferring 
electronic money, via said second cryptographically secure 
session, to said first money module which provisionally 
retains said electronic money; 

(h) said first money module committing, 
whereupon said retention of said electronic money is no 
longer provisional, and securely informing said customer 
trusted agent of successful electronic money receipt; 

(i) said second money module committing, and 
securely informing said merchant trusted agent of successful 
electronic money transfer; 

(j) said customer trusted agent committing, 
whereupon said retention of said receipt ticket is no longer 
provisional ; and 

(k) said merchant trusted agent committing. 

11. ^"The method of ^laim 10, wherein said account 
credential is a credit or debit card ticket having said 
customer's bank account number. 

12 . The method of claim 10 , further including the 
step of said customer trusted agent verifying said receipt 
ticket . 

13 . A method for open distribution of electronic 
money utilizing a customer trusted agent, a first money 
module, a merchant trusted agent, and a second money module, 
comprising the steps of : 
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(a) establishing a first cryptographically 
secure session between said customer trusted agent and said 
merchant trusted agent; 

(b) said customer trusted agent transferring 
electronic money sale information and an account credential 
vxa said first cryptographically secure session, to said 
merchant trusted agent; 

(c) said merchant trusted agent creating a 
receipt ticket including, at least in part, said electronic 
money sale information and said customer's bank account 

nuiciber; 

(d) said merchant trusted agent transferring 
saxd receipt ticket, via said first cryptographically secure 
session, to said customer trusted agent which provisionally 
retains said ticket; 

. ^^^^ merchant trusted agent accessing an 

authorization network and initiating an authorization 
process using information from said electronic money sale 
information and said account credential; 

(f ) establishing a second cryptographically 
secure session between said first money module and said 
second money module; 

(g) said first money module transferring 
electronic money, via said second cryptographically secure 
session, to said second money module which provisionally 
retains said electronic money; 

(h) said first money module committing and 
securely informing said customer trusted agent of successful 
electronic money trcuisfer; 

(i) said second money module committing 
whereupon said retention of said electronic money is „o 
longer provisional, and securely informing said merchant 
trusted agent of successful electronic money receipt; 

(j) said customer trusted agent committing 
whereupon said retention of said receipt ticket is no longer 
provisional; and "-^l-^.**- 
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(k) said merchant trusted agent committing. 

14. The method of claim 13, wherein said account 
credential is a debit or credit card ticket having said 
customer's bank account number. 

15 . The method of claim 13 , further including the 
step of said customer trusted agent verifying said receipt 
ticket . 

16. A system for the secure distribution of 
electronic money comprising: 

a tamper-proof first electronic transaction 
device including a first processor ; 

a tamper-proof second electronic transaction 
device including a second processor and that communicates 
with said first electronic transaction device via a 
cryptographically secure session; 

where said first processor is adapted to 
transfer purchase amoxint information and a customer account 
credential to said second electronic transaction device; 

where said second processor incorporates said 
purchase amoirnt information and information from said 
customer account credential in a receipt ticket and 
transfers said receipt ticket, via said cryptographically 
secure session, to said first electronic transaction device; 

where said second processor initiates an 
authorization process based on said purchase amount 
information and information from sai^ c^ustomer account 
credential; and 

where, in the event aikthorization is 
received, said second electronic transaction device 
transfers electronic money to said - f ^irst electronic 
transaction device, thereby providing for the distribution 
of electronic money independent of whether & customer's bank 
distributes electronic money. >:S^P^^-'- 
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17. The system of claim 16. wherein said second 
electronic transaction device is connected to a merchant 
network and an authorization network connected to a 
customer's bank network; where said authorization process is 
executed over said authorization network. 

18. The system of claim 17, wherein said second 
electronic transaction device is connected to a merchant's 
bank network of a bank that distributes electronic money. 

19. The system of claim 16, wherein said customer 
account credential is a debit or credit card ticket having 
said customer's bank account number. 

20. A system for the secure distribution of 
electronic money comprising: 

a tamper-proof first electronic transaction 
device including a first processor; 

d.^.. . ^ ^^^^'^^ «l«°tronic transaction 

device including a second processor and that comrnunicates 
with said first electronic transaction device via a 
cryptographically secure session; 

where said first processor is adapted to 
transfer electronic money sale information and a customer 
account credential to said second electronic transaction 
device; 

where said second processor incorporates said 
electronic money sale information and information from said 
customer account c^eden^l^i in a receipt ticket and 
transfers said receipt ti|cket. via said cryptographically 
secure session, to said f i^st electronic transaction device; 

where said second processor initiates an 
authorization process based on said electronic money sale 
information and information from said customer account 
credential; and " ' --"uac 
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received, said first electronic transaction device transfers 
electronic money to said second electronic transaction 
device . 

21. The system of claim 20, wherein said seo(»d 
electronic transaction device is connected to a mo-r-otr^ nt 
network and an authorization network connected to a 
customer's bank network; where said authorization process is 
executed over said authorization network. 

22. The system of claim 21, wherein said second 
electronic transaction device is connected to a mezchant's 
bank network of a bank that distributes electronic money. 

23. The system of claim 20, wheiein said customer 
account credential is a debit or credit card ticket .having 
said customer's bank account number. 
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MONEY (SALE) 



MONEY (PURCHASE) 
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MERCHANT 
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IDENTIFIER 


COMPONENTS 


ISSUER 
SIGNATURE 


ISSUER 
CERTIFICATE 


TRANSFER 
HISTORY 


SENDER 
SIGNATURES 


-J. '^-^ -i ' , * 


1 





8 



MERCHANT/ 
AUmORITY 


RECEIVER 


TICKET 
TYPE 




RECEIVER 
ID'S 


SENDER 
ID'S 


SENDER 
CERTS 


DATE/ 
TIMES 


1 1 
22 24 


26 






1 

30 


1 

32 


1 

34 
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BANKID 



ACCOUNT NUMBER 



38 



VAUD FROM DATE 



EXPIRATION DATE 



CUSTOMER NAME 
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